今年3月以后，世界上很多国家都因为新冠疫情的肆虐封锁了边境。英国政府曾提出“群体免疫”策略，不过在参考了一些学术机构的报告后，最终采取的还是封锁隔离政策。而这些学术报告中最值得一提的，就是英国帝国理工学院（IC）的研究报告，该报告建议务必实施严格的封锁。
人们的生活随封锁发生了天翻地覆的变化。当大家不能再随意握手、拥抱，当很多礼节与风俗都需要改变甚至避免时，人们肯定想问，疫情真的有那么严重吗？
疫情就像是怀疑论的温床。英国就有一个叫做“质疑封城”（lockdownsceptics.org）的网站，怀疑论者们会在上面发布一些有关封锁的新闻，并刊载一些反对封锁的观点与分析。
“质疑封城”网站最近的文章——肥胖的人们：你们不用担心死于冠状病毒丨截图
既然不愿相信疫情的严重性，也不断否定封锁政策的价值，怀疑论者当然就要从政策所依赖的研究下手。如果帝国理工学院的研究不再可信了，据此施行封锁还有什么道理呢？
尼尔·弗格森（Neil Ferguson）是一位数学生物学教授，在帝国理工全球传染病分析中心担任疫情建模负责人，他也是整个封锁政策的核心人物。今年5月，因封城期间被爆出破坏自己立的规矩，私会情人，弗格森教授被迫辞职。在他陷入风波的时候，不少怀疑论者更是利用弗格森教授信用危机的机会，对他主导的研究进行批评。
这是一场“带风向”的争论
今年5月初，一名自称是谷歌前员工的人在“质疑封城”网站上发表了一篇文章，内容是对弗格森教授疫情研究所用的代码进行评审。
一名自称是谷歌前员工的人在“质疑封城”网站上发表了一篇文章，内容是对弗格森教授疫情研究所用的代码进行评审丨截图
帝国理工学院会把他们的研究代码上传到github。github 是一个开放源代码、让全世界程序员协作编写软件的网站。既然大家都能看到研究的代码了，那么就可以针对代码进行评审。所谓的代码评审（code review），通常是程序员们你看我写的代码，我看你写的代码，互相挑错，弄完之后项目质量就会变棒棒的一种活动。
而这篇文章并没有对项目的核心部分提出什么有价值的分析与质疑，结论却是“只要用到这项研究代码的论文，都应该立刻被撤回”。这篇文章为“质疑封城”吸引了大量流量，网站月均浏览量从不到10万增长到超过40万。目前文章已经有快700条留言，其中一个用户留言说，要去源代码所在的地方发布一个 issue ，目的呢，也是要求撤回论文。
github issue 就像社区中的帖子一样，是供大家讨论事情的，不过得讨论项目有关的问题，尽量别跑题。让我们先来看下这个项目之前的 issue 是什么样的：
1）某个文件第几行的代码，关于每年有多少天的变量应该是365而不是364，还有会不会其实应该是365.25？下面的回复解释了为什么要用364而不是365，大家都了解以后此 issue 被关闭。
2）某个部分的运行需要测试。回复里有人说，是的呢，但你提到的测试类型不一定合适，你有具体的测试策略吗？之后又有人提出这里有我写的测试代码，若是合适的话请合并到项目里。
也就是说，提出一个 issue ，主要目的在于对这个项目能有所贡献，无论是指出它的问题，还是提出应改进的地方，之后大家围绕项目代码你给点意见我提交下代码，最后这个项目就变得更好了。
可怀疑论者发布的这个 issue 说了些啥呢？“这些代码的测试太烂了，无法用于科学目的，不符合科学方法”，“因为这项研究，几十亿人的生活被打乱”，“作为公共政策，是以此研究非常准确为前提的，这真是个灾难”，“程序员们，请签名以表赞同吧”。
issue：呼吁立即撤回所有以该代码库为基础的论文，请程序员们签名表示赞同。丨截图
帝国理工学院从3年前就在 github 上发布其各项研究所使用的代码，但并没有什么人看。可这样的一个 issue 一经发表，却吸引了很多不明真相的人前来围观。点击收藏此项目的人数从不到300快速增加到了接近900。
弗格森教授其实是重用了13年前用于流感大流行建模的代码，而在发布前它已经在 github 与微软的帮助下大大改进了，参与改进的人还包括传奇程序员、自由软件倡导者约翰·卡马克（John Carmack）。13年在软件工程领域算是不短的时间，并且经过了这么多人的努力，目前的代码已经比较符合现代规范。而事实也证明，英国政府采取帝国理工学院建议的封锁策略后，死亡人数下降为预期的1/28。
故事到此就很清晰了，这个issue明显是要带风向，去否定研究得出的结论。怀疑论者是在利用程序员的身份与专业背景去挑战弗格森的研究，进而表达自己的政治诉求。他们之前就一直在指控是帝国理工学院与弗格森教授让大家倒了霉，整个西方经济都因此停滞。“代码发布在 github 上了？太好了，公开了就好办了，集中炮火打击”，这就是他们的想法。
“代码风格”很重要，却不一定影响结果
可为什么很多程序员这么容易就被人利用了呢？因为上面提到的issue还提到了项目的代码风格很烂，大家一寻思，这种情况下的软件一般都问题不断。据此推测，这项研究也肯定漏洞百出了。
代码风格究竟重不重要其实在软件行业里也是一直受争论的话题。良好的代码风格，特点是使代码易读，比如一个人的名字被用作变量，那么起名叫 name 就比 x 强很多，这不仅利于项目进行中的协作，对之后的维护工作也至关重要。对代码风格的追求主要是因为在现代软件行业中，协作是无法避免的事儿，你写完的代码还得给其他人看，也无可避免地需要修改其他人遗留下的代码。一个项目以后再想加点什么、减点什么、改点这里、修点那里，要是看不懂可就没招儿了，这也就是对软件行业的重构有所帮助。
良好的代码风格，有利于项目进行中的协作，对之后的维护工作也至关重要，但不见得就跟最后的结果有直接关系。丨图虫创意
不过话说回来，很多时候，代码写得漂不漂亮也不见得就跟最后的结果有直接关系。比如之前大火的游戏《太吾绘卷》，它的作者就不咋懂写代码，整得一团乱，但也没碍着作品创意。科研工作怎么写代码，写什么样的代码，是科研人员为了得出结论所用到的手段罢了。这种情况下，可能过程就真没有结果那么重要。
事实上，不少重要的数学代码库都是由科研人员编写，若有意愿的话，他们有能力写出优美健壮的代码。但现实中，不少科研人员都需要迅速发表论文，这时候他们的代码在专业程序员眼中就没那么专业或者严谨了。人人都希望看到质量良好的代码，把代码公开可能是帮助其改进质量的第一步。
公开代码，需要善意的环境
在专业人员的指导下，通过专业方法，科研领域的代码风格应该会越变越好。
当然，一切的前提是善意。都是程序员，有些呢，对缓解新冠疫情作出了自己的贡献，他们根据公开的源代码，提出问题和建议，改进项目。可另一些呢，比如那些怀疑论者们，基本就是在添乱了。立场和偏好会先入为主地影响对事情的判断，即使很多程序员明白代码风格不等同于软件质量或科研成果，还是会因为以上原因去攻击对方。
这些举动是很危险的，它可能会减少科学家们公开代码的动力，甚至还会使得正当的同行评审更加困难。
通过专业方法，科研领域的代码风格应该会越变越好，当然一切的前提是善意。丨图虫创意
每项公共政策乃至每项科学研究都可能有争议，很难让所有人满意，也很难令所有人信服。今年的疫情或许让社会气氛变得更加紧张，什么政策都会被用放大镜检视。
其实之前英国 “气候门”（Climategate）事件就与这次反对封锁的情况有些相像。当时英国东安格里亚大学气候研究小组的邮件往来被黑客入侵，随后该小组被指控操纵数据、伪造科学流程。最终英国独立调查人员在彻底调查后指出：科研人员诚信完好，方法健全，但缺乏透明度，建议公开所有相关的数据与代码。
在此之后，公开研究使用的代码在气候学领域已被普遍实践，那么在其他领域的科学研究中，这种举措是否值得参考？在今年疫情中，把相关研究的代码公开，程序员们或许也能更好地理解科研是如何进行的。与此同时，因为参与开源，所有人都可以为科研代码质量的提高贡献自己的一份力量，建议与批评也都会更加有理有据。
